![【Security Hub修復手順】[KMS.5] KMSキーはパブリックに公開すべきではありません](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-cea52bc8a6ec5cad9021b38df4a08b9e/24c76ee7c1ae7aa7f9676a59c77f8702/aws-security-hub)
【Security Hub修復手順】[KMS.5] KMSキーはパブリックに公開すべきではありません
2024.11.14こんにちは！AWS事業本部の吉田です。
皆さん、お使いのAWS環境のセキュリティチェックはしていますか？
当エントリでは、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[KMS.5] KMSキーはパブリックに公開すべきではありません
[KMS.5] KMS keys should not be publicly accessible
前提条件
本記事は、AWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
本コントロールは、AWS KMSキーがパブリックにアクセス可能か確認します。
KMSキーポリシーで外部アカウントからのアクセスが許可されている場合、
第三者がKMSキーを使用してデータを暗号化および復号化できるようになり、データが流失される可能性があります。
どのようなキーポリシーの場合に検知されるのか？
「KMSキーポリシーで外部アカウントからのアクセスが許可されている場合」＝「クロスアカウントアクセスを許可している場合」に本コントロールが失敗するとも読めてしまいます。
実際、下記の記事のようにKMSキーにクロスアカウントアクセスをすることは往々にしてあると思います。
カスタマーマネージドキーで暗号化されたS3オブジェクトにクロスアカウントアクセスする方法
どのようなKMSキーポリシーを設定している場合、本コントロールで検知されるのか検証します。
結論
まず結論ですが、キーポリシーのPrincipalにIAMユーザーやIAMロールを指定している場合は本コントロールは検知されません。
Principalでワイルドカードを使用していた場合に本コントロールは失敗します。
検証（クロスアカウントアクセスの場合）
以下のキャプチャの通り、まずはキーポリシーのPrincipalに他アカウントのIAMロールを設定します。
本コントロールにリンクしているAWS Configのルールを再評価しても、検証用KMSキーのコンプライアンスのステータスは準拠のままでした。
検証（ワイルドカードの場合）
次にキーポリシーのPrincipalにワイルドカードを使用します。
AWS Configのルールを再評価したところ、検証用KMSキーのコンプライアンスのステータスは非準拠に変わりました。
つまり、キーポリシーのPrincipalでワイルドカードを使用していた場合に本コントロールは失敗します。
修復手順
- KMSの「カスタマー管理型のキー」のページに移動し、対象のKMSキーをクリックします。
- キーポリシーの「編集」をクリックします。
- キーポリシーでPrincipalにワイルドカードを使用しているStatementを探します。
- ワイルドカードの部分を他アカウントのIAMロール・もしくはIAMユーザーのARNに変更した後、「変更の保存」をクリックします。
最後に
今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。
コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう！
最後までお読みいただきありがとうございました！どなたかのお役に立てれば幸いです。
